home *** CD-ROM | disk | FTP | other *** search
-
-
- Chapter 10: Anti-Ruggie Measures 133
-
-
-
-
- 10 Anti-Ruggie Measures
-
-
- __Ruggie__ is short for ``rug-rat''; it's a somewhat mutated term which
- now refers to any brat, twit, twerp, loser, wanker, nud, idiot, len, moron,
- or generally, any walking waste of protoplasm. These types of people
- (often, though by no means exclusively, kids who've just been given their
- first modem for Christmas) may suddenly spring up and begin to plague your
- BBS. They may do any one of a number of things, from logging in and asking
- stupid questions, to putting drivel in the discussion rooms, to strewing
- megabytes of profanity all over your board. If they do the former, then
- you may simply want to take them aside, so to speak, and answer their
- questions. If they do something like the latter, then read on.
-
-
-
- 10.1 Philosophy
-
- ``But first, a brief philosophical interlude.'' The developers of
- Fnordadel have been running conversation-only BBSes for a number of years
- (the Round Table, Royce's board, went up in August of 1984, and Secret
- Service, Adrian's board, has been around since March of 1986). In all that
- time, a philosophy of ``open'' Sysoping has prevailed. That is, we've
- always disliked the validation style of BBSes---the kind where you have to
- leave ten pages of personal information before the Sysop will grant you
- access to his system. We prefer to run systems where anyone can create a
- new account at any time, without Sysoply intervention, and then dive into
- most of what goes on with the system.
-
- The problem with this, of course, is that undesirables tend to slip in.
- Any ruggie can call in and leave his drivel or profanity at any time, and
- there ain't much that the Sysop can do about it. About the most he can
- do, on a standard Citadel, is delete the offending messages as soon as he
- sees them, hopefully before they got sent anywhere if the rooms affected
- are networked, and pray the ruggie doesn't call back. Or he can turn
- his system into a ``closed'', validation-style system, which may not be an
- attractive option. It certainly isn't to us.
-
- Here in Edmonton, we've had a pretty determined gang of ruggies plaguing
- the boards for a couple of years, and it was primarily these twits who
- prompted the development of Fnordadel's anti-ruggie features which aren't
- found on other Citadels.
-
- *Please note:* no security measures ever devised can stop a determined
- incursion, so we advise you to be pretty low-key about what security
- measures you may have in place, to avoid tempting people to break them.
-
-
-
- Chapter 10: Anti-Ruggie Measures 134
-
-
-
-
- 10.2 The Secret Weapons
-
- Here, then, are the tools at your disposal. Use any combination that
- works for you without causing your regular users undue discomfort.
-
-
- 10.2.1 Paranoid mode
-
- Standard Fnordadel requires that users login using their password only;
- if people are intelligent in choosing their passwords, this works fine and
- is quicker than having to type in one's user name as well. Unfortunately,
- many people are not the least bit intelligent when it comes to password
- choosing (or anything else, for that matter), so it leaves a resourceful
- ruggie with some golden opportunities to hack someone's account and cause
- chaos.
-
- If you define the variable #getname to have the value `1' in your
- `ctdlcnfg.sys' (referred to in the literature as ``paranoid mode'', for
- hysterical... err... historical reasons), Fnordadel will ask for both a
- name and a password when logging users in. This means that a ruggie has to
- guess not only a user's password, but to which user the password belongs.
- This is pretty tough.
-
-
-
- 10.2.2 Messages per room per call
-
- A favourite ruggie trick is to use an automated macro to enter one
- message (frequently something short but obscene) into one or more rooms,
- over and over and over again; the goal being to scroll all the real
- messages out of your message base.
-
- To combat this, Fnordadel allows you to define the maximum number of
- messages which any given user can enter in any given room during any one
- login session. (The Mail> room is an exception; see the next section.)
- Simply define the `ctdlcnfg.sys' variable #msgenter to be your desired
- maximum. For most systems, a number like `4' or `5' is pretty good; it
- allows the legitimate users plenty of leeway for verbosity, while helping
- to contain the damage done by a vandal. Deleting 4 or 5 messages from a
- few rooms is much better than deleting hundreds, or having to nuke your
- message base because it's full of ``Sysop Sucks Eggs'' messages.
-
- Setting this parameter to `0' means there is no limit on the number of
- messages enterable by anybody. Even if the value is non-zero, all Aides,
- Co-Sysops and the Sysop are exempt from the limit. Hopefully you won't all
- run wild.
-
-
-
- Chapter 10: Anti-Ruggie Measures 135
-
-
-
-
- 10.2.3 Mail messages per call
-
- The parameter #mailenter in `ctdlcnfg.sys' works exactly like its
- counterpart msgenter described above. It controls only the Mail> room,
- however, and thus allows you to independently alter users' use of private
- mail. Not only can this be used to stop vandals from flooding your decent
- users with junk mail, it can be used to control non-ruggies who may be a
- bit too enthusiastically posting private messages.
-
- Again, setting this parameter to `0' means there is no limit on the
- number of messages enterable by anybody. Aides, Co-Sysops and the Sysop
- are exempt from the limit in any case.
-
- Another parameter to consider in this area is allmail. If set to `1',
- the parameter allows all users full access to entering messages in the
- Mail> room. If set to `0', however, users are not able to enter mail to
- anybody except `Sysop', unless you manually give them mail privileges (see
- Section 5.2 [User Status Commands], page 80). Naturally, Aides, Co-Sysops
- and the Sysop always have full Mail> access. See `flipbits.man' if you
- need a way to set the mail access flag for all users in one swell foop.
-
-
- 10.2.4 Maximum number of calls per day
-
- This parameter is called #maxcalls in `ctdlcnfg.sys', and is used to
- limit the total number of calls any user (except Aides, Co-Sysops and the
- Sysop, of course) may make in a given day. Again, setting the parameter to
- `0' means there is no limit.
-
-
-
- 10.2.5 Maximum connect time per day
-
- This parameter is called #maxtime in `ctdlcnfg.sys', and is used to
- limit the total connect time any user (except Aides, Co-Sysops and the
- Sysop, of course) may use up in a given day. The value is in minutes.
- Again, setting the it to `0' means there is no limit.
-
- This measure is like the others, in that it is non-intrusive---users
- will not be booted off the system the second they exceed their daily
- allotment of connect time. Instead, they will be allowed to finish their
- current login session. But if they call back the same day, they will not
- be permitted entry. This seems to us like a good mix of control for the
- Sysop vs. consideration for the users.
-
- A related parameter that you might want to look at is mincalltime. This
- value is in minutes, and specifies the minimum connect time you wish to
- ``charge'' a user on any call, no matter how short it is. (For example,
- if you set this variable to `5', all calls of five minutes or less will
- be charged as five minutes.) The lowest acceptable value is `1', but you
- can set it higher if you're concerned about users that call frequently but
- spend very little time connected.
-
-
-
- Chapter 10: Anti-Ruggie Measures 136
-
-
-
-
- 10.2.6 Maximum number of close calls per day
-
- Now we get really tricky. First of all, you say, ``What the heck is a
- `close call'? I just about got hit by a truck, is that what you mean?''
- Not quite. We define a close call to be any call made by a user that
- occurs a certain small amount of time after the termination of his/her
- last call. Ruggies frequently do this, as you'll know if you examine
- your `calllog.sys' file after ruggie problems---you'll probably see lots of
- (usually short) calls, one after the other. They will do this for sure
- if you have defined the msgenter parameter, since that value unreasonably
- limits the number of drivelous messages they can post during one call.
-
- Well, there's hope. Simply define the `ctdlcnfg.sys' parameter
- #closetime to be the number of minutes separating what you think are two
- calls that are ``close''. We suggest something like 10 minutes. Next,
- define the parameter maxclosecalls to be the maximum number of close calls
- that users will be allowed on a daily basis. We suggest a number somewhere
- between 3 and 5 if you're having problems, but be aware that you'll also be
- putting the clamps on any decent users that have bad line noise problems or
- call-waiting on their phone lines (they'll get disconnected frequently and
- probably try calling back right away).
-
- If either of the above parameters is set to `0', there is (you got it)
- no limit. Also, predictably, Aides, Co-Sysops and the Sysop are exempt
- from the limit. Be aware, when setting maxclosecalls, that all users start
- each day with this stat set to `1'. Their first call is by definition
- close to itself. Make sense?
-
-
- 10.2.7 Daily download limit
-
- For those users that may be downloading stuff like crazy, you may want
- to set a limit on how much they can do in a day. Use the `ctdlcnfg.sys'
- parameter #download, which is a number defining the maximum number of
- kilobytes of files downloadable by any user (except Aides, Co-Sysops and
- the Sysop) per day. If the value is `0', there is, of course, no limit.
-
-
-
- 10.2.8 Twit status
-
- This is the ``twit-bit''; it's a flag in the user log record to tell the
- system that the user is, as they say, a twit. To set it, use the [T]wit
- toggle command from the [U]ser status sub-menu under the Sysop menu (see
- Section 5.2 [User Status Commands], page 80).
-
- What does the twit-bit do, you ask? The most useful function of the
- twit-bit is to cause all messages entered by twits to be saved not to
- the message base, but to the Great Bit Bucket In The Sky. (I.e., they
- are thrown away the nanosecond the user hits [S]ave.) Note that this
- is different from the purge feature, covered in Section 10.2.10 [Message
- purging], page 137, where local messages from undesirables are actually
- saved, but then automatically deleted later.
-
- In addition, certain Fnordadel functions will be mysteriously
- inoperative or different for a twit.
-
-
-
- Chapter 10: Anti-Ruggie Measures 137
-
-
-
-
- o A twit may not use the [C]hat command.
-
- o He/she may not upload or download files.
-
- o Doors are inaccessible to a twit.
-
- o The command `.RG' for reading all new messages on the system will be
- mapped to [N]ew.
-
- o A twit will not be allowed to use .E(nter) R(oom).
-
- o As a sort of side-effect, no new users will be allowed to login to the
- system immediately after a twit has [T]erminated. (This is to stop his
- buddies, or new aliases with him attached.) As soon as one existing
- user signon has occured, new users will once again be allowed to
- login. (This function assumes that you're not running your Fnordadel
- in validation mode. See Section 10.2.14 [Closed system], page 140.)
-
-
- 10.2.9 Inheritance
-
- Another favorite trick of ruggies is to play around with the
- .T(erminate) S(tay) feature---that form of .T(erminate) which allows the
- user to stay connected and login again (presumably under a different
- alias).
-
- Fnordadel makes an assumption which is pretty accurate, most of the
- time. It assumes that anyone who logs in after a twit has used `.TS'
- is also a twit, and assigns him/her twit status just as if the Sysop had
- manually done so.
-
- Currently, Fnordadel allows only twit status to be inherited; the
- capability may be extended to include purging and whatever else may arise.
-
-
-
- 10.2.10 Message purging
-
- This is probably the goofiest yet most useful of the ruggie control
- features, mainly because it's the most devious. Essentially, it allows
- Fnordadel to automatically delete all messages from specified users,
- immediately upon said users' disconnection from the system. Also, if
- you set the `ctdlcnfg.sys' parameter #purgenet to `1', all incoming net
- messages (except in Mail>) from specified users *or net nodes* will be
- purged.
-
- Place a file called `purge.sys' into your #sysdir. It should contain a
- list of user or node names, one per line, to whom the purge will apply.
- Case is irrelevant, since all name comparisons during searches ignore case.
- Now invoke citadel with `+purge' on the command line.
-
- When Fnordadel is brought up it reads the contents of `purge.sys' into
- memory. When a user [T]erminates, or a network session finishes, the list
- is checked. New messages from the desired users and nodes are deleted,
- except for those posted in the Mail> room (this gives them a chance to
- talk to you and redeem themselves). The deleted messages will appear in
-
-
-
- Chapter 10: Anti-Ruggie Measures 138
-
-
-
-
- Aide> in the case of locally-entered messages; they will be marked by `The
- following message deleted from xyz> by Citadel'.
-
- You can modify this behavior by setting the `ctdlcnfg.sys' variable
- #vaporize to `1'. If you do this, your system will actually ``roll back''
- all messages (including those in Mail>) entered by the ruggie, reclaiming
- the space they took up in the message base. This action is logged in
- Aide>. Note that if the user caused any Aide> messages to be generated
- during his/her stay, they will be lost along will all the other user
- messages when the vaporization occurs. This fact is logged in Aide> also,
- but the lost Aide> messages themselves are not recoverable, unless you
- are archiving the room. See Section 4.2.1 [Sysop room-editing commands],
- page 70.
-
- Normal purging takes a little time, but vaporize mode takes even longer.
- Use with caution (if it screws up, it will probably toast your message
- base), and only if you are being plagued with so many ruggie postings
- that they're causing serious space wastage in your message base. Better
- yet, if you're having this much trouble, consider moving and changing your
- identity.
-
- The purge list can be maintained by using a text editor on the
- `purge.sys' file when the BBS is down; and by the use of the [P]urge
- sub-menu under the Sysop menu when when the BBS is up. See Section 10.2.12
- [Purge and Westwict menus], page 139, for details on how the menu works.
-
- The purge feature works fairly well; however, it does nothing to make
- your message base impervious to having loads of crap dumped in it in the
- first place. If you want to stop the messages from being entered while
- still keeping your system up, you have only two choices: use the twit
- status bit a lot (see Section 10.2.8 [Twit status], page 136) or go to
- validation mode (see Section 10.2.14 [Closed system], page 140).
-
- Note also that Fnordadel makes no check to see that names in `purge.sys'
- are those of existing users on your system; this allows you to add the
- names of ruggies who may have been terrorising other boards but not yours.
- You can prepare in advance for their arrival. Also, once a ruggie has hit
- your system, he may leave it alone long enough for his user account to
- scroll out of your user file. If he ever signs back on with the same name,
- however, he will still be purged immediately.
-
- Finally, the purge function can be applied to incoming net traffic as
- well as locally-entered messages. This can be effective in eliminating
- dreck from problem net nodes to which you don't connect directly. Even
- better, net messages eliminated by the purger never make it into your
- message base, so they cause no space wastage. They are either permanently
- lost, or saved each in its own offline file for you to manually process.
- See #purgenet and #keepdiscards in Section 8.1.2 [Optional Networking
- Parameters], page 98, and the [D]iscarded messages menu in Section 8.2 [The
- Net Menu], page 104.
-
-
-
- Chapter 10: Anti-Ruggie Measures 139
-
-
-
-
- 10.2.11 Login restrictions
-
- This doesn't really qualify as an anti-ruggie feature, in the truest
- sense, but we'll put it here anyway because it's similar.
-
- Put a file called `restrict.sys' in your #sysdir containing a list of
- user names, one per line. When Fnordadel is brought up it reads the list
- into memory. If you specify `+restrict' on the citadel command line,
- or if you manually turn on restrictions using the [W]estwict command in
- the Sysop menu, then Fnordadel will restrict logins to only those users
- named in `restrict.sys'. All other attempted logins, whether by new users
- or by existing users, will be refused---the system will spit out the
- `restrict.blb' file, located in your #helpdir, or a simple ``sorry, the
- system is closed'' message if it can't find `restrict.blb'.
-
- In the ruggie-control sense, login restrictions could be used to
- restrict access to your system to only those users that you know are
- ``safe'', without having to actually process their applications and create
- their accounts yourself (as required by ``validation'' mode). As with
- purging, it has the advantage that you may specify the names of users
- who have never logged in, so you can ``reserve a spot'' for them, as it
- were. (Of course, this is itself a security hole, because a ruggie can try
- to guess who you've got in your restrict list... but let's not get too
- paranoid.)
-
- Login restrictions were originally put in during a round of hacking on
- the software in which we were constantly interrupted during testing by
- users calling the board; we wanted to reserve the board for ourselves,
- without disabling it. Another possible use for login restrictions is to
- designate a certain time period for ``members only'' or some such; simply
- set up a pair of events which exit to a command shell, where a script file
- copies a new `restrict.blb' into place, and then reruns citadel. The first
- event set the restriction to ``members only'', and the second event resets
- things to open access. The possibilities are endless!
-
-
- 10.2.12 Purge and Westwict menus
-
- The purge and restrict lists may be manipulated using these two menus.
- Their operation is identical. The commands are:
-
- [A]dd name to list
- [D]elete name from list
- [S]witch function on/off
- [V]iew list in RAM
- [W]rite list to disk
- e[X]it menu
-
- [A]dd name to list
- This allows you to add another name to the list. No check is
- made to see whether the name is that of a currently-existing
- user; this is deliberate. (See below).
-
- [D]elete name from list
- Use this to remove someone from the list.
-
-
-
- Chapter 10: Anti-Ruggie Measures 140
-
-
-
-
- [S]witch function on/off
- This toggles purging/restrictions on or off. If it is off, the
- list will still be kept in memory, so the feature can be turned
- on again at any time.
-
- [V]iew list in RAM
- This displays a list of the names currently in the list stored
- in memory.
-
- [W]rite list to disk
- After you've made some changes to the list, you'll probably
- want to make them permanent. Use this command to write the
- contents of the list in RAM to disk (as the file `purge.sys'
- or `restrict.sys'.) The old file, if it exists, will be
- overwritten.
-
- e[X]it menu
- Exit back to the main Sysop menu.
-
-
- 10.2.13 Network security
-
- If you suspect another Citadel net node is actively causing you grief
- (or if you just want to play it safe/paranoid), there are a few things you
- can do to protect your system. The first is to set up net passwords with
- the systems you normally net with, assuming you trust them (see [P]asswords
- in Section 8.3 [Editing Nodes], page 107.) There have been incidents in
- the past where unscrupulous Sysops set up systems that looked exactly like
- other systems, and then dialed in to places in order to intercept shared
- rooms and Mail>, and generally cause chaos. Net passwords were put in to
- prevent this behavior.
-
- Two other things you can do are to set the anonnetmail and/or
- #anonfilexfer parameters in `ctdlcnfg.sys'. These parameters, if set to
- `0', will make your system reject attempted incoming net mail and file
- transfer requests, respectively, if the sending node is not in your net
- list. This prevents rogue systems from scrolling your Mail> room and
- message base, or filling up all available disk storage. It would also
- prevent the ``junk mail'' phenomenon, which is already a problem with fax
- machines. Heaven help us all if it hits BBS networks.
-
-
-
- 10.2.14 Closed system
-
- So, let's say that everything else has failed. The ruggies have found
- out about all of the above features, and have found workarounds for all
- of them. Or they haven't, but have enough time and perseverence to keep
- plugging away with every automated macro and trick they can come up with.
- What do you do now?
-
- Much as we hate to suggest it, the best option is probably to close
- your system. To do so, simply change the value of the `ctdlcnfg.sys'
- variable #loginok to 0. This will prevent new users from creating their
- own accounts; they will only be able to leave mail to the Sysop to request
- that you create an account for them. You will then have total control over
-
-
-
- Chapter 10: Anti-Ruggie Measures 141
-
-
-
-
- who gets access to your system; unfortunately, you'll also have opened up a
- whole new can of problem worms, such as ruggies who request bogus accounts
- by just randomly pulling names from the phone book. At this point, you
- should be talking to your phone company about getting an unlisted phone
- number, and perhaps a line trace. They might be willing to help you out.
-
- In conjunction with this step, you may also need to define the
- `ctdlcnfg.sys' parameter called #anonmailmax, which controls the size of
- mail messages enterable by users that aren't logged in. This will help
- prevent ruggies who can no longer log in from causing you problems in
- Mail>, the last room available to them.
-
-
-
- 10.3 Other Hints and Notes
-
- o When using the purge feature on incoming net traffic, make sure that
- none of the user names in your purge list is the same as any net node
- you get messages from. The results are obvious, and highly annoying.
-
- Also, the net purge currently is set to be very literal about matching
- user names on other nodes---no substring matching is done. This
- prevents messages from `Dr. Zamboni' from being blown away along with
- those from `Dr. Zam'. However, it is marginally possible (due to all
- the strange and wonderful variants of Citadel out there) that messages
- from `Dr. Zam' would not be purged due to some software somewhere
- sticking extra crap in the user name field, e.g. `Dr. Zam @ Foobar'.
- This isn't supposed to happen, but it might. We'll figure something
- out to get around it when/if it becomes a problem.
-
- o When users exceed any of the limit values you have defined, the system
- keeps track of the excess amount over and above the maximums, and rolls
- that amount forward to future days. This is done like so: When the
- user calls back any day after today (could be many days from now), the
- system subtracts from his/her accumulated stats the maximum values you
- set. It then checks to see if the user should be allowed access;
- if not, the new lower limit values are saved and the user is logged
- off. Thus users who abuse your system (especially in the total connect
- time area) could penalize themselves for several days. Note: The
- system does not care if the user calls back tomorrow or four weeks from
- now. No extra deductions from the user's accumulated stats are made if
- he/she waits for several days or weeks to call back.
-
- Also note: If a user makes a call and is prevented access due to one
- or another of your defined limits, the call is counted and recorded
- against their time and number of calls limits, even though the user was
- not allowed onto the system.
-
- Final note: If you don't like this behavior of rolling overages
- forward, you can get rid of it using the `ctdlcnfg.sys' parameter
- #autozerolimit. If set to `1', this flag tells the system to
- graciously wipe out all the user's limit values and start from scratch,
- rather than bringing forward any extra amounts.
-
-
-
- Chapter 10: Anti-Ruggie Measures 142
-
-
-
-
- o If you need to manually reset a user's limit statistics, for some
- reason, you can do so using the [R]eset daily limits command of the
- user status menu. You can look at a user's current stats using the
- [V]iew user status command in the same menu. See Section 5.2 [User
- Status Commands], page 80.
-
- o The system pauses for about 20 seconds on bad passwords, to discourage
- password guessing. After a certain number of bad login attempts
- (currently 3), the system will disconnect the caller.
-
- o If you're having ruggie problems and haven't got as far as closing your
- system yet, you'll want to make sure that you aren't being too careless
- with the new users' privileges. The `ctdlcnfg.sys' variable #allnet is
- a good one to check; if it's set to `1', all new users are given net
- privs (and can therefore enter net messages in shared rooms, whether
- the room is autonet or not). If you net long-distance rooms (or even
- just local ones), it would be both a profound annoyance for all the
- other Sysops, and a possibly expensive proposition in the case of LD
- netting, to send out a flood of messages from a ruggie who was allowed
- to post net messages in a shared room. Be careful. (See Chapter 8
- [Networking], page 96.)
-
-